Only save pause timestamp if app is unlocked #20
Conversation
|
Adding |
|
Hi Charlton, thanks for your suggestion and pull request! I need to do some testing with this; will come back to it later. A quick question I have while observing the code; why don't you just get the |
|
Hi @Bassiuz .last is returning a Future. At first I thought I could just await this, but it only seemingly only retreives the event when a new one is emmitted. https://api.flutter.dev/flutter/dart-async/Stream/last.html - This is due to the LockState being a BroadcastStream, it does not remember past events. Apologies if I am misunderstanding how to get the last value from this Stream - I'm relativity new to using Flutter. |
|
Hi @CharltonSantana , you're right, I was making some quick assumptions on a friday afternoon (my bad :) ). I think I like the approach as the controller itself is small enough. I was thinking about maybe a listener setup instead but that would make the controller too convoluted. The only remark I have is that I think the if statement doesn't compile like this right? Instead of it should be something like this right? |
|
Hi @Bassiuz Yes this should be an AND. I have commited a fix for the AND statement, I messed up when doing the first commit - my bad. Yeah I've mulled it over and I too think having if on the controller itself is the best place for storing the last value. |
|
Hi @Bassiuz, Any update re if this PR will be merged? |
Hello,
I have identified and addressed an issue related to the didChangeAppLifecycleState behavior when interacting with Face ID. During the 'unlockWithBiometrics' , didChangeAppLifecycleState receives an inactive/paused state. This led to the unintended triggering of the lockout duration check immediately after the Face ID authentication was completed.
There seems to be an inconsistnty in how often didChangeAppLifecycleState recieves this state.
The problematic sequence was as follows:
This behavior was not isolated to our app but was also observed in your example application.
To rectify this issue, I have modified the behavior to consider the app's lock status before storing the 'paused timestamp'. It is unnecessary to execute the lock duration check if the app is already in a locked state when it goes inactive.
I'm currently uncertain about how best to retreive the current lock status so i have made a slight change to lock_controller.dart. Happy to change this ofcourse.
Your feedback on this approach and its integration into the existing codebase would be greatly appreciated. Thank you for your attention to this matter.
Best regards,
Charlton Santana